Providing data verification in a blockchain ledger

ABSTRACT

Implementations of this specification provide a method and an apparatus for providing data verification in a blockchain ledger. An example method includes receiving, from a client and by a database server that is configured to store data using the blockchain ledger, an instruction that includes a verification method parameter and a verification range parameter for the database server. The verification method parameter is used to indicate a computing device on which verification is to be performed, and the verification range parameter includes a block height or a hash value, and is used to determine a range of a to-be-verified data block or a data record in the ledger. The database server determines the computing device on which verification is to be performed, based on the verification method parameter. The database server determines to-be-verified data based on the verification range parameter.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT Application No.PCT/CN2020/071884, filed on Jan. 14, 2020, which claims priority toChinese Patent Application No. 201910314334.9, filed on Apr. 18, 2019,and each application is hereby incorporated by reference in itsentirety.

TECHNICAL FIELD

Implementations of the present specification relate to the field ofinformation technologies, and in particular, to a data verificationmethod, system, apparatus, and device in a blockchain ledger.

BACKGROUND

When a centralized database server stores data by using a blockchainledger, a user often initiates various verification to the server.During verification, based on user needs, some verification needs to becompleted on a client, and some verification needs to be completed onthe server. In addition, verification ranges are often different.

Therefore, there is a need for a solution in which data verification canbe flexibly performed in a blockchain ledger.

SUMMARY

An objective of implementations of the present application is to providea data verification solution in a blockchain ledger.

To alleviate the previous technical problem, the implementations of thepresent application are implemented as follows:

A data verification method in a blockchain ledger is applied to a systemincluding a database server and a client, where the database serverstores data by using the blockchain ledger in a centralized way, and themethod includes: sending, by the client, an instruction that includes averification method parameter and a verification range parameter to thedatabase server, where the verification method parameter is used toinstruct to perform verification on the database server or performverification on the client; the verification range parameter includes ablock height or a hash value, and is used to determine a range of ato-be-verified data block or a data record in the ledger; determining,by the database server, to-be-verified data based on the verificationrange parameter, where the to-be-verified data includes one of a datarecord, a data block, a partial ledger, or an entire ledger; verifying,by the database server, integrity of the to-be-verified data when theverification method parameter instructs to perform verification on thedatabase server, and returning a verification result to the client;returning, by the database server, the to-be-verified data to the clientwhen the verification method parameter instructs to perform verificationon the client, and verifying, by the client, integrity of theto-be-verified data to generate a verification result.

Correspondingly, an implementation of the present specification furtherprovides a data verification system in a blockchain ledger. The systemincludes a database server and a client. The database server stores databy using the blockchain ledger in a centralized way.

In the system, the client sends an instruction that includes averification method parameter and a verification range parameter to thedatabase server, where the verification method parameter is used toinstruct to perform verification on the database server or performverification on the client; the verification range parameter includes ablock height or a hash value, and is used to determine a range of ato-be-verified data block or a data record in the ledger; the databaseserver determines to-be-verified data based on the verification rangeparameter, where the to-be-verified data includes one of a data record,a data block, a partial ledger, or an entire ledger; the database serververifies integrity of the to-be-verified data when the verificationmethod parameter instructs to perform verification on the databaseserver, and returns a verification result to the client; the databaseserver returns the to-be-verified data to the client when theverification method parameter instructs to perform verification on theclient, and the client verifies integrity of the to-be-verified data togenerate a verification result.

Correspondingly, an implementation of the present specification furtherprovides a data verification method in a blockchain ledger, applied to adatabase server that stores data by using the blockchain ledger in acentralized way, and the method includes: receiving an instruction thatincludes a verification method parameter and a verification rangeparameter, where the verification method parameter is used to instructto perform verification on the database server or perform verificationon a client; the verification range parameter includes a block height ora hash value, and is used to determine a range of a to-be-verified datablock or a data record in the ledger; determining to-be-verified databased on the verification range parameter, where the to-be-verified dataincludes one of a data record, a data block, a partial ledger, or anentire ledger; verifying, by the database server, integrity of theto-be-verified data when the verification method parameter instructs toperform verification on the database server, and returning averification result to the client; returning, by the database server,the to-be-verified data to the client when the verification methodparameter instructs to perform verification on the client, so the clientverifies integrity of the to-be-verified data.

Correspondingly, an implementation of the present specification furtherprovides a data verification apparatus in a blockchain ledger, appliedto a database server that stores data by using the blockchain ledger ina centralized way, and the apparatus includes: a receiving module,configured to receive an instruction that includes a verification methodparameter and a verification range parameter, where the verificationmethod parameter is used to instruct to perform verification on thedatabase server or perform verification on a client; the verificationrange parameter includes a block height or a hash value, and is used todetermine a range of a to-be-verified data block or a data record in theledger; a determining module, configured to determine to-be-verifieddata based on the verification range parameter, where the to-be-verifieddata includes one of a data record, a data block, a partial ledger, oran entire ledger; a verification module, configured to verify, by thedatabase server, integrity of the to-be-verified data when theverification method parameter instructs to perform verification on thedatabase server, and return a verification result to the client; asending module, configured to return, by the database server, theto-be-verified data to the client when the verification method parameterinstructs to perform verification on the client, so the client verifiesintegrity of the to-be-verified data.

According to solutions provided in implementations of the presentspecification, when initiating a verification request, a user includes arelated verification method parameter and verification range parameterto the request, so a server can determine, based on the verificationmethod parameter, whether to perform verification on the server or on aclient, and determine a verification range based on the verificationrange parameter, so as to execute a corresponding verification method.The implementations can flexibly implement data verification in ablockchain ledger.

It should be understood that the previous general description and thefollowing detailed description are merely exemplary and illustrative,and does not limit the implementations of the present specification.

In addition, any one of the implementations in the present specificationdoes not need to achieve all the previous effects.

BRIEF DESCRIPTION OF DRAWINGS

To describe the technical solutions in the implementations of thepresent specification or in the existing technology more clearly, thefollowing briefly describes the accompanying drawings needed fordescribing the implementations or the existing technology. Apparently,the accompanying drawings in the following description merely show someimplementations of the present specification, and a person of ordinaryskill in the art can still derive other drawings from these accompanyingdrawings.

FIG. 1 is a schematic flowchart of generating a data block in ablockchain ledger, according to an implementation of the presentspecification;

FIG. 2 illustrates a data verification method in a blockchain ledger,according to an implementation of the present specification;

FIG. 3 is a schematic flowchart illustrating a data verification methodon a database server, according to an implementation of the presentspecification;

FIG. 4 is a schematic structural diagram illustrating a dataverification apparatus in a blockchain ledger on a database server,according to an implementation of the present specification;

FIG. 5 is a schematic structural diagram illustrating a device used toconfigure a method in an implementation of the present specification.

DESCRIPTION OF IMPLEMENTATIONS

To make a person skilled in the art better understand the technicalsolutions in the implementations of the present specification, thefollowing describes in detail the technical solutions in theimplementations of the present specification with reference to theaccompanying drawings in the implementations of the presentspecification. Apparently, the described implementations are merely somebut not all of the implementations of the present specification. Allother implementations obtained by a person of ordinary skill in the artbased on the implementations of the present specification shall fallwithin the protection scope of the present specification.

First, a centralized blockchain ledger in the present specification isdescribed.

In a centralized database service provider involved in theimplementations of the present specification, one ledger includesmultiple data blocks, and the data blocks are pre-generated in thefollowing way. FIG. 1 is a schematic flowchart of generating a datablock in a blockchain ledger, according to an implementation of thepresent specification. The process includes:

S101. Receive to-be-stored data records, and determine a hash value ofeach data record, where the to-be-stored data records here can bevarious consumption records of an individual user of a client, or can bea service result, an intermediate state, an operation record, etc. thatare generated when an application server executes service logic based onan instruction of the user; can include a consumption record, an auditlog, a supply chain, a government supervision record, a medical record,etc. in specific service scenarios.

S103. When a predetermined blocking condition is met, determine eachdata record to be written into a data block to generate an Nth datablock that includes a hash value of the data block and the data record.

The predetermined blocking condition includes: The number ofto-be-stored data records reaches a number threshold. For example, eachtime one thousand data records are received, one new data block isgenerated, and the one thousand data records are written into the block.Or a time interval counting from a previous blocking moment reaches atime threshold. For example, one new data block is generated every fiveminutes, and a data record received within the five minutes is writteninto the block.

N refers to a serial number of a data block. In other words, in thisimplementation of the present specification, data blocks are arranged ina form of block-chain and in a sequence of blocking moments, and have astrong time sequence characteristic. Block heights of the data blocksare monotonically increased based on a sequence of blocking moments. Theblock height can be a serial number, and in this case, the block heightof the Nth data block is N. The block height can also be generated inanother method.

When N=1, the data block is an initial data block. A hash value and ablock height of the initial data block are given based on apredetermined method. For example, the initial data block does notinclude a data record, a hash value is any given hash value, and a blockheight blknum=0. For another example, a trigger condition for generatingthe initial data block is consistent with a trigger condition foranother data block, but the hash value of the initial data block isdetermined by hashing all content in the initial data block.

When N>1, because content and a hash value of a previous data block aredetermined, a hash value of a current data block (the Nth data block)can be generated based on the hash value of the previous data block(that is, the (N−1)th data block). For example, in a feasible method,hash values of all data records to be written into the Nth block aredetermined, and a Merkle tree is generated based on an arrangementsequence of the data records in the block. A root hash value of theMerkle tree is concatenated with the hash value of the previous datablock to generate the hash value of the current data block by using ahash algorithm. For another example, a hash value of the entire datarecord can be obtained by performing concatenation and hashing based onthe sequence of data records in the block. The hash value of the entiredata record is concatenated with the hash value of the previous datablock to obtain a character string. A hash operation is performed on thecharacter string to generate the hash value of the data block.

When a server generates one data block and writes the data block intothe ledger, a hash value of the data block and a hash value of each datarecord in the data block can be returned to a client.

According to the previous data block generation method, each data blockis determined by using a hash value, and the hash value of the datablock is determined by content and a sequence of data records in thedata block, and a hash value of a previous data block. The user caninitiate verification at any time based on the hash value of the datablock. Modification to any content in the data block (including thecontent or the sequence of data records in the data block) causes adifference between a hash value of the data block calculated duringverification and a hash value of the data block during generation, whichcauses a verification failure, thereby avoiding tampering in thecentralized scenario.

Specifically, integrity of a data record is verified by obtaining thedata record and determining a hash value of the data record and a hashvalue of another data record in a data block in which the data record islocated, to form a Merkle tree and verify whether a root hash of theMerkle tree can be regenerated. A data block is verified byrecalculating a hash value of the data block based on a hash value of aprevious data block and a data record of the data block, and verifyingwhether the hash value is consistent with a previously calculated hashvalue. In addition, the data record corresponding to the hash value canbe directly returned to the user, so the user can directly perform ahash operation on the data record to verify integrity.

As described above, after the data of the user is stored in the ledger,the user can initiate verification to the server. It is worthwhile tonote that, in the implementation of the present specification, althoughthe blockchain ledger is similar to a blockchain, in the implementationof the present specification, the database server provides servicesexternally in a centralized way, which is essentially different from theblockchain.

In a blockchain system, because services are de-centralized, a clientcan initiate data verification to any node that has permission toperform verification. The blockchain system can ensure consistency ofdata returned by all nodes. A user can trust a result returned by thenode. In other words, the client does not need to locally perform dataverification.

However, in the implementation of the present specification, thedatabase server is in a centralized way. Therefore, if both data storageand data verification are completed on the server, a result is notnecessarily trustworthy for a user. Therefore, some users hope tocomplete corresponding data verification on the client.

In addition, in a blockchain ledger, some verification resources areless consumed, such as verifying whether a data record exists in theledger. However, some verification resources are greatly consumed, suchas verifying data integrity of an entire ledger. It can be difficult forsome client devices to support the greatly consumed resources.

Accordingly, an implementation of the present specification provides asolution in which flexible data verification can be performed in ablockchain ledger.

The technical solutions provided in the implementations of the presentspecification are described in detail below with reference to theaccompanying drawings. FIG. 2 illustrates a data verification method ina blockchain ledger, according to an implementation of the presentspecification. The method is applied to a system including a databaseserver and a client. The database server stores data by using theblockchain ledger in a centralized way. The process specificallyincludes the following steps:

S201. The client sends an instruction that includes a verificationmethod parameter and a verification range parameter to the databaseserver.

Specifically, a user can initiate a verification instruction by usingthe client, and the verification instruction specifies, by using theverification range parameter, data blocks on which verification isinitiated. The verification range parameter can be a block height or ahash value.

For example, a data block can be specified by using a hash value toinitiate verification on the data block. Or a value is further added tospecify whether correct verification is initiated on multiple datablocks before or after the data block. Or a data record is specified byusing a hash value to verify whether the data record exists in adatabase.

In addition, the verification instruction can further include theverification method parameter, where the verification method parameteris used to indicate the user's needs, and instruct to perform currentverification on the database server or on the client. It is worthwhileto note that the verification instruction can include only theverification range parameter, and the verification method parameter canbe omitted. In this case, a default verification method is performed onthe server.

The following provides examples of several verification instructionforms provided in the implementation of the present specification, andthe verification method is omitted.

Example 1: The instruction includes a hash value of the verificationrange parameter, and the hash value corresponds to a data record or acertain data block. The server verifies the data block to obtain averification result. Specifically, a verification instructionVERIFY(‘khash’, &v) can be used for implementation. “khash” is a hashvalue entered by the user, “&v” is a return result of currentverification, and after verification ends, the server assigns a value to“&v”.

Example 2: The instruction includes a hash value of the verificationrange parameter, and the hash value is used to determine a correspondingdata block, or is used to determine a data block in which a data recordcorresponding to the hash value is located. The verification instructionis used to perform verification forward starting from the determineddata block until an initial data block. Specifically, verificationinstruction VERIFY(‘khash’, &v, −1) can be used for implementation.Generally, an initial block height is “0” or “1”. Therefore, −1 can alsobe another value that is less than the initial block height. Therefore,a serving party can know that this parameter is not a very small blockheight value, which means that verification continues unit the initialdata block.

Example 3: The instruction includes a hash value of the verificationrange parameter, and the hash value is used to determine a correspondingdata block. A specified number of data blocks are verified forwardstarting from the determined data block. Specifically, verificationinstruction VERIFY(‘khash’, &v, blknum) can be used for implementation,where khash is a hash value entered by the user, and “blknum” is thenumber of to-be-verified data blocks specified by the user.

Example 4: The instruction includes a block height of the verificationrange parameter, and a specified number of consecutive data blocks areverified forward starting from a data block corresponding to the blockheight. Specifically, verification instruction VERIFY(blkh, &v, blknum)can be used for implementation. “blkh” is a hash value entered by theuser, “blknum” is the number of to-be-verified data blocks specified bythe user, and blknum can be 1 or omitted, that is, only one data blockis verified currently. Or blknum can be a large number. If the value ofblknum exceeds the ledger number in the ledger, it indicates that entireledger verification needs to be performed for current verification.

Example 5: The instruction includes two block height values of theverification range parameter. Specifically, verification instructionVERIFY(blkh1, blkh2, &v) can be used for implementation, where blkh1 andblkh2 are used to determine a block height interval of a data block incurrent verification.

Further, in the verification instruction, the verification methodparameter can be added to determine to perform verification on theserver or on the client.

For example, after the verification method parameter is added, the firstverification instruction becomes VERIFY(Remote, ‘khash’, &v) orVERIFY(Client, ‘khash’, &v). “Remote” indicates that currentverification is performed on the server, and “Client” indicates that thecurrent verification is performed on the client.

For another example, after the verification method parameter is added,the fourth verification instruction becomes VERIFY(Client, blkh, &v, 1),indicating that current verification on a data block with a certainblock height is completed on the client.

S203. The database server determines to-be-verified data based on theverification range parameter, where the to-be-verified data includes oneof a data record, a data block, a partial ledger, or an entire ledger.

In the blockchain ledger, a hash value can uniquely represent one datarecord or one data block, and the block height can also uniquelyidentify one data block. Therefore, based on the verification rangeparameter, to-be-verified data corresponding to a current instructioncan always be determined.

“Corresponds to” in this implementation of the present specificationmeans that a hash value can be obtained by performing a hash operationon a data record or a data block, and a correspondence exists betweenthe hash value and the data record or the data block.

Specifically, after receiving the verification instruction, the databaseserver can parse the instruction to obtain a hash value or a blockheight of a corresponding verification range parameter. Further, thedatabase server can perform traversal query to verify whether the hashcorresponds to a certain data record or data block; or query and obtaina block height and an offset that correspond to the hash value from anindex table, and then obtain a corresponding data record based on theread block height and offset.

For example, for the first verification instruction that includes thehash value, that is, VERIFY(Remote, ‘khash’, &v), the server obtains thehash value of the instruction and performs matching query on the hashvalue in a pre-established data record index table (data record hashvalue, block height, offset in a block height), to obtain a block heightand an offset of a data block in which the data record is located,further determine a data record corresponding to the hash value, anddetermine the data record as to-be-verified data.

It is worthwhile to note that, in the instruction, the user does notneed to specify “khash” as the hash value of the data record or the hashvalue of the data block. The server can obtain through querying, in atraversal way, an object corresponding to the hash value from theledger, or obtain through querying, from a pre-established data recordhash index/data block hash index (including a correspondence between adata block hash value and a data block height), the object correspondingto the hash value.

For another example, for the fifth instruction that includes the datablock height, that is, VERIFY(Client, 100, 300, &v), the database servercan determine a block height interval [100, 300] based on block heights100 and 300, and determine a partial ledger corresponding to a datablock whose block height falls into the interval as to-be-verified data.

S205. Verify integrity of the to-be-verified data.

Specifically, the database server verifies the integrity of theto-be-verified data when the verification method parameter instructs toperform verification on the database server, and returns a verificationresult to the client. The verification result can be displayed byassigning a value to “&v” in the verification instruction.

The database server returns the to-be-verified data to the client whenthe verification method parameter instructs to perform verification onthe client, and the client verifies integrity of the to-be-verified datato generate a verification result. A specific method for verifyingintegrity of the data record or the ledger is described in the previousdescription, and details are omitted here.

According to solutions provided in implementations of the presentspecification, when initiating a verification request, a user includes arelated verification method parameter and verification range parameterto the request, so a server can determine, based on the verificationmethod parameter, whether to perform verification on the server or on aclient, and determine a verification range based on the verificationrange parameter, so as to execute a corresponding verification method.The implementations can flexibly implement data verification in ablockchain ledger.

In an implementation, further an indicative prefix or suffix field canbe added to the verification method parameter, so the server can moreeffectively parse the instruction.

For example, prefix Tx is added to the verification method to indicatethat current verification is performed for a data record on the client,and a form of the verification instruction is therefore VERIFY(TxClient,khash, &v), so the server can directly query a data record correspondingto khash.

In an implementation, when the verification method parameter instructsto perform verification on the client, and there is related data forverification on the client, the server only needs to send theto-be-verified data.

In an implementation, when determining the to-be-verified data, thedatabase server can further determine, based on an operationinstruction, other auxiliary verification data needed for verification,and send the other auxiliary verification data to the client.

For example, when the user initiates the fourth verification instructionto verify a specified data block, VERIFY(Client, blkh, &v, 1) indicatesthat a data block specified by a block height blkh needs to be verifiedon the client. The database server can obtain through matching acorresponding data block as the to-be-verified data based on the blockheight blkh. In addition, in the process of verifying a data block, ahash value of a previous data block of the data block needs to be used.Therefore, the database server can further obtain “the hash value of theprevious data block” as auxiliary verification data and directly sendthe auxiliary verification data to the client.

For another example, when the user initiates the first verificationinstruction (refer to example 1), that is, VERIFY(Client, ‘khash’, &v),whether a specified data record exists in the ledger is verified on theclient. During the verification, a Merkle tree consisting of datarecords in a data block needs to be first determined, so as to determinea Merkle path of the data record in the Merkle tree. In other words, ahash value of another data record on the Merkle path and a root hash ofthe Merkle tree need to be used. In this case, the database server cansend the hash value of the another data record on the Merkle path andthe root hash of the Merkle tree to the client as auxiliary verificationdata, or directly send content of the entire data block to the client assufficient verification data (generally, when the user that initiatesverification has permission to access all the content).

In practice, when resources are insufficient on the client, a selectivecheck can be performed randomly on a data block in the ledger. Forexample, a data block height is randomly specified for verification onthe client. Or several hash values are selected to perform existenceverification on data records corresponding to the hash values on theclient. When the above-mentioned selective check and verification arepassed, verification is initiated on a partial ledger or the entireledger on the server. Certainly, when resources are sufficient, theserver can also be requested to deliver data and perform verification onthe entire ledger locally. As such, in a centralized scenario, theuser's requirements on integrity of the ledger are met, and flexibleverification on the centralized ledger is implemented.

Correspondingly, an implementation of the present specification furtherprovides a data verification system in a blockchain ledger. The systemincludes a database server and a client. The database server stores databy using the blockchain ledger in a centralized way.

In the system, the client sends an instruction that includes averification method parameter and a verification range parameter to thedatabase server, where the verification method parameter is used toinstruct to perform verification on the database server or performverification on the client; the verification range parameter includes ablock height or a hash value, and is used to determine a range of ato-be-verified data block or a data record in the ledger; the databaseserver determines to-be-verified data based on the verification rangeparameter, where the to-be-verified data includes one of a data record,a data block, a partial ledger, or an entire ledger; the database serververifies integrity of the to-be-verified data when the verificationmethod parameter instructs to perform verification on the databaseserver, and returns a verification result to the client; the databaseserver returns the to-be-verified data to the client when theverification method parameter instructs to perform verification on theclient, and the client verifies integrity of the to-be-verified data togenerate a verification result.

Further, in the system, when the verification range parameter is thehash value, the database server queries and obtains a data recordcorresponding to the hash value, and determines the data record and/or adata block in which the data record is located as the to-be-verifieddata; or the database server queries and obtains a data blockcorresponding to the hash value, and determines the data block as theto-be-verified data.

Further, in the system, when the verification range parameter is theblock height, the database server determines a data block correspondingto the block height, and determines the data block as the to-be-verifieddata; or the database server determines a partial or an entire ledgercorresponding to an interval formed by two block heights, and determinesthe partial or the entire ledger as the to-be-verified data.

Further, in the system, when the verification method parameter instructsto perform verification on the client, the database server determinesother auxiliary verification data needed when the client verifies theto-be-verified data, and sends the to-be-verified data and the otherauxiliary verification data to the client.

Further, on the centralized database server, the data block ispre-generated by: receiving to-be-stored data records and determining ahash value of each data record, where the data record includes aspecified identifier field; when a predetermined blocking condition ismet, determining each data record to be written into a data block togenerate an Nth data block that includes a hash value of the data blockand the data record, which specifically includes: when N=1, giving ahash value and a block height of an initial data block based on apredetermined method; when N>1, determining a hash value of the Nth datablock based on each data record to be written into the data block and ahash value of an (N−1)th data block, generate the Nth data block thatincludes the hash value of the Nth data block and each data record,where block heights of data blocks are increased monotonically based ona sequence of blocking moments.

Further, in the system, the predetermined blocking condition includes:the number of to-be-stored data records reaches a number threshold; or atime interval counting from a previous blocking moment reaches a timethreshold.

Correspondingly, an implementation of the present specification furtherprovides a data verification method in a blockchain ledger. The methodis applied to a database server that stores data by using the blockchainledger in a centralized way. FIG. 3 is a schematic flowchartillustrating a data verification method on a database server, accordingto an implementation of the present specification. The method includes:

S301. Receive an instruction that includes a verification methodparameter and a verification range parameter, where the verificationmethod parameter is used to instruct to perform verification on thedatabase server or perform verification on a client; the verificationrange parameter includes a block height or a hash value, and is used todetermine a range of a to-be-verified data block or a data record in theledger.

S303. Determine to-be-verified data based on the verification rangeparameter, where the to-be-verified data includes one of a data record,a data block, a partial ledger, or an entire ledger.

S305. The database server verifies integrity of the to-be-verified datawhen the verification method parameter instructs to perform verificationon the database server, and returns a verification result to the client.

S307. The database server returns the to-be-verified data to the clientwhen the verification method parameter instructs to perform verificationon the client, so the client verifies integrity of the to-be-verifieddata.

Correspondingly, an implementation of the present specification furtherprovides a data verification apparatus in a blockchain ledger. FIG. 4 isa schematic structural diagram illustrating a data verificationapparatus in a blockchain ledger on a database server, according to animplementation of the present specification. The apparatus includes: areceiving module 401, configured to receive an instruction that includesa verification method parameter and a verification range parameter,where the verification method parameter is used to instruct to performverification on the database server or perform verification on a client;the verification range parameter includes a block height or a hashvalue, and is used to determine a range of a to-be-verified data blockor a data record in the ledger; a determining module 403, configured todetermine to-be-verified data based on the verification range parameter,where the to-be-verified data includes one of a data record, a datablock, a partial ledger, or an entire ledger; a verification module 405,configured to verify, by the database server, integrity of theto-be-verified data when the verification method parameter instructs toperform verification on the database server, and return a verificationresult to the client; a sending module 407, configured to return, by thedatabase server, the to-be-verified data to the client when theverification method parameter instructs to perform verification on theclient, so the client verifies integrity of the to-be-verified data.

An implementation of the present specification further provides acomputer device. The computer device includes at least a memory, aprocessor, and a computer program that is stored in the memory and thatcan run on the processor. When executing the program, the processorimplements the data verification method in a blockchain ledger shown inFIG. 2.

FIG. 5 is a more detailed schematic diagram illustrating a hardwarestructure of a computing device, according to an implementation of thepresent specification. The device can include a processor 1010, a memory1020, an input/output interface 1030, a communications interface 1040,and a bus 1050. The processor 1010, the memory 1020, the input/outputinterface 1030, and the communications interface 1040 arecommunicatively connected to each other inside the device by using thebus 1050.

The processor 1010 can be implemented by using a general centralprocessing unit (CPU), a microprocessor, an application-specificintegrated circuit (ASIC), one or more integrated circuits, etc., and isconfigured to execute a related program, so as to implement thetechnical solutions provided in the implementations of the presentspecification.

The memory 1020 can be implemented by using a read-only memory (ROM), arandom access memory (RAM), a static storage device, a dynamic storagedevice, etc. The memory 1020 can store an operating system and anotherapplication program. When the technical solutions provided in theimplementations of the present specification are implemented by usingsoftware or firmware, related program code is stored in the memory 1020,and is invoked and executed by the processor 1010.

The input/output interface 1030 is configured to be connected to aninput/output module, to input or output information. The input/outputmodule (not shown in the figure) can be used as a component andconfigured in the device, or can be externally connected to the device,to provide a corresponding function. The input module can include akeyboard, a mouse device, a touchscreen, a microphone, various sensors,etc. The output module can include a monitor, a speaker, a vibrator, anindicator, etc.

The communications interface 1040 is configured to be connected to acommunications module (not shown in the figure), to implement acommunication interaction between the device and another device. Thecommunications module can perform communication in a wired way (forexample, USB or a network cable), or can perform communication in awireless way (for example, a mobile network, Wi-Fi, or Bluetooth).

The bus 1050 includes one channel, used to transmit information betweencomponents (for example, the processor 1010, the memory 1020, theinput/output interface 1030, and the communications interface 1040) ofthe device.

It is worthwhile to note that although only the processor 1010, thememory 1020, the input/output interface 1030, the communicationsinterface 1040, and the bus 1050 of the device are shown, duringspecific implementation, the device can further include other componentsneeded for implementing normal running. In addition, a person skilled inthe art can understand that the device can include only componentsnecessary for implementing the solutions in the implementations of thepresent specification, but does not necessarily include all componentsshown in the figure.

An implementation of the present specification further provides acomputer readable storage medium on which a computer program is stored.When being executed by a processor, the program implements the dataverification method in a blockchain ledger shown in FIG. 2.

The computer readable medium includes persistent, non-persistent,movable, and unmovable media that can store information by using anymethod or technology. The information can be a computer readableinstruction, a data structure, a program module, or other data. Examplesof the computer storage medium include but are not limited to a phasechange random access memory (PRAM), a static RAM (SRAM), a dynamic RAM(DRAM), a RAM of another type, a read-only memory (ROM), an electricallyerasable programmable ROM (EEPROM), a flash memory or another memorytechnology, a compact disc ROM (CD-ROM), a digital versatile disc (DVD),or another optical storage, a cassette, a cassette magnetic diskstorage, or another magnetic storage device or any othernon-transmission medium. The computer storage medium can be configuredto store information that can be accessed by a computing device. Asdescribed in the present application, the computer readable medium doesnot include computer readable transitory media such as a modulated datasignal and a carrier.

It can be seen from the previous descriptions of the implementationsthat, a person skilled in the art can clearly understand that theimplementations of the present specification can be implemented by usingsoftware and a necessary general hardware platform. Based on such anunderstanding, the technical solutions in the implementations of thepresent specification essentially or the part contributing to theexisting technology can be implemented in a form of a software product.The computer software product can be stored in a storage medium, such asa ROM/RAM, a magnetic disk, or an optical disc, and includes severalinstructions for instructing a computer device (which can be a personalcomputer, a server, a network device, etc.) to perform the methoddescribed in the implementations of the present specification or in someparts of the implementations of the present specification.

The system, method, module, or unit illustrated in the previousimplementations can be implemented by using a computer chip or anentity, or can be implemented by using a product having a certainfunction. A typical implementation device is a computer, and thecomputer can be a personal computer, a laptop computer, a cellularphone, a camera phone, a smartphone, a personal digital assistant, amedia player, a navigation device, an email receiving and sendingdevice, a game console, a tablet computer, a wearable device, or anycombination of these devices.

The implementations in the present specification are described in aprogressive way. For same or similar parts of the implementations,references can be made to the implementations. Each implementationfocuses on a difference from other implementations. Particularly, adevice implementation is similar to a method implementation, andtherefore is described briefly. For a related part, references can bemade to some descriptions in the method implementation. The previouslydescribed apparatus implementations are merely examples. The modulesdescribed as separate parts can or cannot be physically separate. Duringimplementation of the solutions in the implementations of the presentapplication, functions of the modules can be implemented in one or morepieces of software and/or hardware. Some or all of the modules can beselected based on an actual need to implement the solutions of theimplementations. A person of ordinary skill in the art can understandand implement the implementations of the present application withoutcreative efforts.

The previous descriptions are merely specific implementations of theimplementations of the present application. It is worthwhile to notethat a person of ordinary skill in the art can further make severalimprovements or polishing without departing from the principle of theimplementations of the present application, and the improvements orpolishing shall fall within the protection scope of the implementationsof the present application.

What is claimed is:
 1. A computer-implemented method comprising:receiving, from a client and by a database server that is configured tostore data using a blockchain ledger, an instruction that comprises averification method parameter and a verification range parameter for thedatabase server, wherein the verification method parameter is used toindicate a computing device on which verification is to be performed,and wherein the verification range parameter comprises a block height ora hash value, and is used to determine a range of a to-be-verified datablock or a data record in the ledger; determining, by the databaseserver, the computing device on which verification is to be performed,based on the verification method parameter; and determining, by thedatabase server, to-be-verified data based on the verification rangeparameter, wherein the to-be-verified data comprises one of a datarecord, a data block, a partial ledger, or an entire ledger.
 2. Themethod according to claim 1, further comprising: in response to theverification method parameter indicating that verification is to beperformed on the database server: determining, by the database server,that verification is to be performed on the database server; verifying,by the database server, integrity of the to-be-verified data; andreturning, by the database server, a verification result to the client.3. The method according to claim 1, further comprising: in response tothe verification method parameter indicating that verification is to beperformed on the client: determining, by the database server, thatverification is to be performed on the client; sending, by the databaseserver and to the client, the to-be-verified data for verification bythe client.
 4. The method according to claim 3, wherein sending theto-be-verified data for verification by the client comprises:determining, by the database server, other auxiliary verification datafor use by the client when verifying the to-be-verified data, andsending the to-be-verified data and the other auxiliary verificationdata to the client.
 5. The method according to claim 1, whereindetermining, by the database server, to-be-verified data based on theverification range parameter comprises: in response to the verificationrange parameter being the hash value: querying and obtaining, by thedatabase server, a data record corresponding to the hash value, anddetermining the data record and/or a data block in which the data recordis located as the to-be-verified data; or querying and obtaining, by thedatabase server, a data block corresponding to the hash value, anddetermining the data block as the to-be-verified data.
 6. The methodaccording to claim 1, wherein determining, by the database server,to-be-verified data based on the verification range parameter comprises:in response to the verification range parameter being the block height:determining, by the database server, a data block corresponding to theblock height, and determining the data block as the to-be-verified data.7. The method according to claim 1, wherein determining, by the databaseserver, to-be-verified data based on the verification range parametercomprises: in response to the verification range parameter being theblock height: determining, by the database server, a partial or anentire ledger corresponding to an interval formed by two block heights,and determining the partial or the entire ledger as the to-be-verifieddata.
 8. The method according to claim 1, wherein on the databaseserver, the data block is pre-generated by: receiving to-be-stored datarecords and determining a hash value of each data record, wherein thedata record comprises a specified identifier field; and in response to apredetermined blocking condition being met, determining each data recordto be written into a data block to generate an Nth data block thatcomprises a hash value of the data block and the data record.
 9. Themethod according to claim 8, further comprising: when N=1, giving aninitial hash value and an initial block height of an initial data blockbased on a predetermined method.
 10. The method according to claim 8,further comprising: when N>1, determining a hash value of the Nth datablock based on each data record to be written into the data block and ahash value of an (N−1)th data block, to generate the Nth data block thatcomprises the hash value of the Nth data block and each data record,wherein block heights of data blocks are increased monotonically basedon a sequence of blocking moments.
 11. The method according to claim 8,wherein the predetermined blocking condition being met comprises: anumber of to-be-stored data records reaching a number threshold.
 12. Themethod according to claim 8, wherein the predetermined blockingcondition being met comprises: a time interval counting from a lastblocking moment reaching a time threshold.
 13. A computer-implementedsystem, comprising: one or more computers; and one or more computermemory devices interoperably coupled with the one or more computers andhaving tangible, non-transitory, machine-readable media storing one ormore instructions that, when executed by the one or more computers,perform operations comprising: receiving, from a client and by adatabase server that is configured to store data using a blockchainledger, an instruction that comprises a verification method parameterand a verification range parameter for the database server, wherein theverification method parameter is used to indicate a computing device onwhich verification is to be performed, and wherein the verificationrange parameter comprises a block height or a hash value, and is used todetermine a range of a to-be-verified data block or a data record in theledger; determining, by the database server, the computing device onwhich verification is to be performed, based on the verification methodparameter; and determining, by the database server, to-be-verified databased on the verification range parameter, wherein the to-be-verifieddata comprises one of a data record, a data block, a partial ledger, oran entire ledger.
 14. The system according to claim 13, the operationsfurther comprising: in response to the verification method parameterindicating that verification is to be performed on the database server:determining, by the database server, that verification is to beperformed on the database server; verifying, by the database server,integrity of the to-be-verified data; and returning, by the databaseserver, a verification result to the client.
 15. The system according toclaim 13, the operations further comprising: in response to theverification method parameter indicating that verification is to beperformed on the client: determining, by the database server, thatverification is to be performed on the client; sending, by the databaseserver and to the client, the to-be-verified data for verification bythe client.
 16. The system according to claim 15, wherein sending theto-be-verified data for verification by the client comprises:determining, by the database server, other auxiliary verification datafor use by the client when verifying the to-be-verified data, andsending the to-be-verified data and the other auxiliary verificationdata to the client.
 17. A non-transitory, computer-readable mediumstoring one or more instructions executable by a computer system toperform operations comprising: receiving, from a client and by adatabase server that is configured to store data using a blockchainledger, an instruction that comprises a verification method parameterand a verification range parameter for the database server, wherein theverification method parameter is used to indicate a computing device onwhich verification is to be performed, and wherein the verificationrange parameter comprises a block height or a hash value, and is used todetermine a range of a to-be-verified data block or a data record in theledger; determining, by the database server, the computing device onwhich verification is to be performed, based on the verification methodparameter; and determining, by the database server, to-be-verified databased on the verification range parameter, wherein the to-be-verifieddata comprises one of a data record, a data block, a partial ledger, oran entire ledger.
 18. The computer-readable medium according to claim17, the operations further comprising: in response to the verificationmethod parameter indicating that verification is to be performed on thedatabase server: determining, by the database server, that verificationis to be performed on the database server; verifying, by the databaseserver, integrity of the to-be-verified data; and returning, by thedatabase server, a verification result to the client.
 19. Thecomputer-readable medium according to claim 17, the operations furthercomprising: in response to the verification method parameter indicatingthat verification is to be performed on the client: determining, by thedatabase server, that verification is to be performed on the client;sending, by the database server and to the client, the to-be-verifieddata for verification by the client.
 20. The computer-readable mediumaccording to claim 19, wherein sending the to-be-verified data forverification by the client comprises: determining, by the databaseserver, other auxiliary verification data for use by the client whenverifying the to-be-verified data, and sending the to-be-verified dataand the other auxiliary verification data to the client.